In general, this should be fixed by explicitly specifying a minimal permissions block either at the workflow root (applies to all jobs) or on the specific job. For a CodeQL analysis workflow that only needs to read the code and upload results, the recommended least-privilege baseline is to grant read access to repository contents and security events, and (if needed) write access only where uploading security results is required.

The single best fix here, without altering behavior, is to add a workflow-level permissions block after the on: section and before jobs:. A conservative, widely recommended configuration for CodeQL is:

permissions:
  contents: read
  security-events: write

This allows the workflow to read the repository contents and upload CodeQL results as security events, while preventing broader write access with GITHUB_TOKEN. Concretely, in .github/workflows/codeql.yml, insert these three lines between the existing pull_request: block (line 10–11) and the jobs: block (line 12). No imports or additional definitions are required.

In general, the fix is to add an explicit permissions: block either at the workflow root (applies to all jobs) or under the specific job, granting only the minimal scopes required. Since this job simply invokes a reusable workflow and no direct write operations are visible here, a safe minimal default is contents: read, which matches GitHub’s recommended read‑only scope for most CI jobs.

The best targeted fix without changing existing functionality is to add a workflow‑level permissions: block after the on: section (lines 3–10) and before jobs: (line 12). This will apply to ragger_tests and any future jobs unless they override it, and it clearly documents that the workflow should only read repository contents. No imports or additional methods are required; this is purely a YAML configuration change in .github/workflows/ragger-tests.yml.

In general, the fix is to declare an explicit permissions: block either at the root of the workflow (applies to all jobs) or under the specific job, granting only the minimal access needed. For a typical unit test workflow that does not need to write to the repo, a safe baseline is contents: read. If the reusable workflow needs more granular permissions (e.g., to comment on PRs), those can be added there, but we should not assume them here without seeing that file.

The single best minimal fix without changing functionality is to add a root‑level permissions: block right under the name: (or under on:) that sets the GITHUB_TOKEN to read‑only for repository contents. This will apply to unit_tests and any future jobs unless they override it. Concretely, in .github/workflows/unit-tests.yml, insert:

permissions:
  contents: read

between the existing name: Unit Tests line and the on: block (or directly above jobs:; both are valid). No additional imports, methods, or definitions are required since this is a YAML configuration change only.